Distributed transactions are often performed on distributed computing systems. A distributed transaction is a set of operations that update shared resources. Distributed transactions must satisfy the properties of Atomicity, Consistency, Isolation and Durability, known commonly as the ACID properties. According to the Atomicity property, either the transaction successfully executes to completion, and the effects of all operations are recorded, or the transaction fails. The Consistency property requires that the transaction does not violate integrity constraints of the shared resources. The Isolation property requires that intermediate effects of the transaction are not detectable to concurrent transactions. Finally, the Durability property requires that changes to shared resources due to the transaction are permanent.
After an application has been compiled and deployed, an administrator may determine that the application should be transactional. The administrator then modifies the source code of the application to make objects within the application transactional. A transactional object is defined herein as an object that can participate in transactions. A transactional object may include semantics for participating in transactions, such as methods for rolling back and committing state changes associated with a transaction. Making an object transactional can add significant overhead to the object. However, it can be difficult to identify which of the application's objects should be made transactional. If everything in the application is accessed transactionally (e.g., all objects are made transactional), then it is guaranteed that there are transactional semantics in place to recover the objects. Accordingly, all of the application's objects are often made transactional to provide maximum safety and recoverability.
There are different locking strategies that can be used for a transactional object. For example, a transactional object can be configured to request read locks or to request write locks. Write locks require more overhead than read locks, but provide added safety. It can be difficult to identify what locking strategy should be used for each object in an application. Since write locks are the safest locks, often all of the objects are given a locking strategy that implements write locks.
When an application is made transactional, each of the objects in the application are often made into transactional objects that request write locks, incurring a maximum possible added overhead. This happens despite the fact that often only some of the objects included in the application actually need to be made transactional, and of those, only some of the objects need write locks.